home *** CD-ROM | disk | FTP | other *** search
/ The Very Best of Atari Inside / The Very Best of Atari Inside 1.iso / sharew / dfue / midi.net / anetmidi / midispec / sdsfmt.txt < prev    next >
Encoding:
Text File  |  1990-12-26  |  8.9 KB  |  233 lines
  1.                            MIDI SAMPLE DUMP STANDARD
  2.  
  3. 1) INTRODUCTION
  4.  
  5.      The  MIDI  SDS  was  adopted  in  January  1986   by   the   MIDI
  6. Manufacturers  Association  and the Japanese MIDI Standards Committee.
  7. The SDS defines the standard method for transfer of sound sample  data
  8. between  MIDI-equipped devices.  Sample dumps may be accomplished with
  9. either an 'open loop' or 'closed loop' system.  The open  loop  method
  10. simply  involves  the straight dump of all sample data from its source
  11. to the destination, with no timeouts, packet acknowledgements,  or any
  12. other form of handshaking, much as in the manner of a sysex bulk dump,
  13. usually intiated at the source.  The closed loop method allows the use
  14. of handshaking messages between the dump source and  destination,  and
  15. usually  places  the  dump process under the control of the slave,  to
  16. allow it time to process the incoming data as necessary.  As with  any
  17. standard, it can not be assumed that a device adheres to it unless the
  18. accompanying documentation specifically indicates it. Even then, it is
  19. best to check its conformity with non-critical data.
  20.  
  21. 2) SPEC: SAMPLE DUMP FORMATS
  22.  
  23.      DUMP HEADER:
  24.  
  25. F0 7E cc 01 ss ss ee ff ff ff gg gg gg hh hh hh ii ii ii jj F7
  26.  
  27. where
  28.  
  29. cc       =     channel number
  30. ss ss    =     sample number (LSB first)
  31. ee       =     sample format (number of significant bits; 8->28)
  32. ff ff ff =     sample period (1/sample rate) in nanoseconds (LSB first)
  33. gg gg gg =     sample length, in words
  34. hh hh hh =     sustain loop start point (word number) (LSB first)
  35. ii ii ii =     sustain loop end point (word number) (LSB first)
  36. jj       =     loop type (00:forwards only; 01:alternating)
  37.  
  38.      DATA PACKET:
  39.  
  40. F0 7E cc 02 kk <120 bytes> mm F7
  41.  
  42. where
  43.  
  44. cc       =     channel number
  45. kk       =     running packet count (00->7F)
  46. mm       =     checksum (XOR of 7E, cc, 02, kk <120 bytes>)
  47.  
  48.      The  total  size of a data packet is 127 bytes.  This is to avoid
  49. overflow of the MIDI input buffer of a device that may want to receive
  50. an entire packet before processing it.
  51.      A data packet consists of its own header,  a packet  number,  120
  52. bytes of data, a checksum, and an EOX.  The packet number begins at 00
  53. and increments with each new packet.  It resets to 00 after it reaches
  54. 7F, and continues counting.  The packet number is used by the receiver
  55. to distinguish between a new data packet,  or a resend of  a  previous
  56. packet. The packet number is followed by 120 bytes of data, which form
  57. 60,  40,  or 30 words (MSB first for multiword samples),  depending on
  58. the length of a single data sample.
  59.      Each data byte hold seven bits,  with the msb in each byte set to
  60. 0,  in order to conform to the requirements of MIDI data transmission.
  61. Information is left justified within the 7-bit bytes,  and unused bits
  62. are filled with 0.
  63.      Example:  Assume  a data point in the memory of a 16-bit sampler,
  64. with the value 87E5. In binary, that would be
  65.  
  66.                           1000 0111 1110 0101
  67.  
  68. and would be encoded as the following MIDI data stream:
  69.  
  70.                       01000011 01111001 00100000
  71.  
  72.      The checksum is the running XOR of all the data after  the  SYSEX
  73. byte, up to but not including the checksum itself.
  74.  
  75. 3) SPEC: SAMPLE DUMP MESSAGES
  76.  
  77.      DUMP REQUEST:
  78.  
  79. F0 7E cc 03 ss ss F7
  80.  
  81. where
  82.  
  83. cc       =     channel number
  84. ss ss    =     sample number requested (LSB first)
  85.  
  86.      Upon receiving the request,  the sampler checks the sample number
  87. to see if it is within legal range.  If it  is  not,  the  request  is
  88. ignored. If it is, the sample dump is started. One packet at a time is
  89. sent, under control of the handshaking messages outlined below.
  90.  
  91.      HANDSHAKING MESSAGES:
  92.  
  93.      For all below:
  94.  
  95. cc       =     channel number
  96. pp       =     packet number
  97.  
  98.      Packet  numbers  are  included  in  the  handshaking  messages to
  99. accomodate machines that have the intelligence to re-transmit specific
  100. packets after an entire dump is finished,  or  if  synchronization  is
  101. lost.
  102.  
  103.      ACK :     F0 7E cc 7F pp F7
  104.  
  105.      Means  last  packet  was  recieved correctly (checksum OK,  etc),
  106. please send next one.  Packet number is packet being  acknowledged  as
  107. correct.
  108.  
  109.      NAK :     F0 7E cc 7E pp F7
  110.  
  111.      Means  last  packet  not  received correctly,  please send again.
  112. Packet number is packet being rejected.
  113.  
  114.      CANCEL :  F0 7E cc 7D pp F7
  115.  
  116.      Means abort dump immediately.  Packet number is packet  on  which
  117. abort occurs.
  118.  
  119.      WAIT   :  F0 7E cc 7C pp F7
  120.  
  121.      Means pause dump indefinitely, until next message is sent. Allows
  122. the  unit  recieving the dump to perform other functions (disk access,
  123. etc), before receiving the remainder of the dump.  The next message it
  124. sends (eg ACK, ABORT) will determine if the dump continues or aborts.
  125.  
  126. 4) DUMP PROCEDURE: MASTER (DUMP SOURCE)
  127.  
  128.      Once  a  dump has been requested,  either via MIDI or through the
  129. front panel,  the DUMP HEADER is sent.  After sending the header,  the
  130. master  must time out for at least two seconds,  to allow the receiver
  131. to decide if it will accept this sample (has enough memory, etc).
  132.      If it receives a  CANCEL,  within  this  time,  it  should  abort
  133. immediately.  If  it  receives  an CAK,  it will start sending packets
  134. immediately. If it receives a WAIT, it pauses until another message is
  135. received,  and then processes that  mesage  normally.  If  nothing  is
  136. recieved  within  the timeout,  an open loop is assumed,  and the dump
  137. starts with the first packet.
  138.      After sending each packet,  the master should  time  out  for  at
  139. least 20 milliseconds and watch its MIDI In. If an ACK is received, it
  140. sends  the  next  packet immediately.  If it receives an NAK,  and the
  141. packet number matches the number of the last packet  sent,  it  resend
  142. that  packet  If  the  packet  numbers don't match,  and the device is
  143. incapable of sending packets out of order, the NAK will be ignored.
  144.      If a WAIT is received,  the master should watch its MIDI In  port
  145. indefinitely for another ACK,  NAK, or CANCEL message, which it should
  146. then process normally.
  147.      If no  messages  are  received  within  20  milliseconds  of  the
  148. transmission  of  a  packet,  the  master  may  assume  an  open  loop
  149. configuration, and send the next packet.
  150.      This process continues until there are less than 121  data  bytes
  151. to send. The final packet will still consist of 120n bytes, regardless
  152. of  how  many significant bytes actually remain,  and the unused bytes
  153. will be filled  with  zeroes.  The  receiver  should  handshake  after
  154. receiving the last packet.
  155.  
  156. 5) DUMP PROCEDURE: SLAVE (DUMP DESTINATION)
  157.  
  158.      When  receiving  a  sample  dump,  a device should keep a running
  159. checksum during reception. If its checksum matches the checksum in the
  160. data packet,  it will send an ACK and wait for the next packet.  If it
  161. does  not  match,  it  will  send  an NAK containing the number of the
  162. packet that caused the error, and wait for the next packet.  If, after
  163. sending an NAK, the packet number of the next packet doesn't match the
  164. previous  packet number (the one that was NAK'd),  and the unit is not
  165. capable of accepting packets out of order,  the error is  ignored  and
  166. the dump continues as if the checksums had matched.
  167.      If  a  receiver runs out of memory before the dumpo is completed,
  168. it should send a CANCEL to stop the dump.
  169.  
  170. 6) SDS OVERVIEW
  171.  
  172.      SAMPLE DUMP DATA FORMAT: DUMP HEADER:
  173.  
  174.      Sysex
  175.          ID: Universal Non-Real Time
  176.          Channel Number
  177.          Sub ID: Header
  178.          Sample Number (2 bytes, LSB first)
  179.          Sample Format
  180.          Sample Period (3 bytes, LSB first)
  181.          Sample Length (3 bytes, LSB first)
  182.          Sustain Loop Start Point (3 bytes, LSB first)
  183.          Sustain Loop End Point (3 bytes, LSB first)
  184.          Loop Type
  185.      Eox
  186.  
  187.      SAMPLE DUMP DATA FORMAT: DATA PACKET:
  188.  
  189.      Sysex
  190.          ID: Universal Non-Real Time
  191.          Channel Number
  192.          Sub ID: Data Packet
  193.          Packet Number
  194.          Sample Data (120 bytes)
  195.          Checksum
  196.      Eox
  197.  
  198.      SAMPLE DUMP MESSAGES: DUMP REQUEST:
  199.  
  200.      Sysex
  201.          ID: Universal Non-Real Time
  202.          Channel Number
  203.          Sub ID: Dump Request
  204.          Sample Number (2 bytes, LSB first)
  205.      Eox
  206.  
  207.      SAMPLE DUMP MESSAGES: HANDSHAKING FLAGS:
  208.  
  209.      Sysex
  210.          ID: Universal Non-Real Time
  211.          Channel Number
  212.          Sub ID: ACK or NAK or CANCEL or WAIT
  213.          Packet Number
  214.      Eox
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
  224. Received: by decpa.pa.dec.com; id AA00121; Fri, 21 Dec 90 17:20:39 -0800
  225. Received: by decwrl.dec.com; id AA29910; Fri, 21 Dec 90 17:11:23 -0800
  226. Message-Id: <9012220111.AA29910@decwrl.dec.com>
  227. Received: from AUVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7293; Fri, 21 Dec 90 20:10:13 EST
  228. Received: by AUVM (Mailer R2.07) id 6660; Fri, 21 Dec 90 20:09:51 EST
  229. Date:         Fri, 21 Dec 90 20:09:49 EST
  230. From: Revised List Processor (1.6e) <LISTSERV%AUVM.BITNET@CUNYVM.CUNY.EDU>
  231. Subject:      File: "SDSFMT MIDISPEC" being sent to you
  232. To: SKIVT::hearn
  233.